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1 Related Applications 

2 This application claims the benefit of U.S. Provisional Application No. 

3 60/358,387, entitled SYSTEM AND METHOD FOR INTERACTIVE WAGERING 

4 FROM A REMOTE LOCATION, filed on February 22, 2002. That application is hereby 

5 incorporated by reference in its entirety. 
6 

7 Copyright Notice 

8 A portion of the disclosure of this patent document contains material that is 

9 subject to copyright protection. The copyright owner has no objection to the facsimile 

10 reproduction by anyone of the patent disclosure, as it appears in the Patent and 

1 1 Trademark Office patent files or records, but otherwise reserves all copyright rights 

12 whatsoever. 
13 

14 BACKGROUND OF THE INVENTION 

1 5 Field of the Invention 

16 The present invention relates generally to wagering. More specifically, the 

17 invention relates to interactive wagering from remote locations. 
18 

19 



f 1 

1 RelatedArt 

2 The practice of wagering on the outcome of uncertain events has been with us for 

3 centuries. In addition to casino-type games, in which outcomes are often random or 

4 semi-random (e.g. based on a combination of skill and luck of the draw or roll), betting 

5 on contests of skill and/or ability has become quite common. For example, many people 

6 enjoy betting on such events as sports contests, including games like football, basketball, 

7 baseball, jai alai and others, and races between such competitors as auto drivers, dogs and 

8 horses. For many, a trip to the track has become a popular pastime, while others may 

9 even deem it their profession. However, it may sometimes be inconvenient to physically 

10 attend such events. Thus, there has long been a need for a way to place bets remotely. 

1 1 Off-track betting establishments, which may be more numerous and/or more 

12 conveniently located than the event venues themselves, are generally known. In addition 

13 to receiving bets, these locations may further provide outcome information, such as by 

14 ticker or television broadcast. 

15 Avenues are also available for placing bets for certain events by telephone. 

16 However, the systems that receive such wagers often do not provide any detailed event 

17 information, such as outcome details, racing programs or other paraphernalia, individual 

18 statistics, etc. 

19 Another approach is to use dedicated devices such as the Tiny TIM, provided by 

20 Autotote Systems, Inc., of Newark, DE, or the BetMate device provided by AmTote, of 

21 Hunt Valley, MD. Such devices typically enable modem communications between an 

22 off-track betting location and an event location, through which bets may be made. Any 
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1 feedback from such devices tends to be provided to users on simple displays, often 

2 making display of detailed event information difficult. Furthermore, such modem-to- 

3 modem arrangements are typically limited to local communications, as the costs 

4 associated with long-range diai-up communications tend to be prohibitive. Thus, these 

5 arrangements are undesirable, particularly for interstate, intercontinental, or other wide 

6 area wagering systems. 

7 Other dedicated devices may receive event information over higher bandwidth 

8 channels, such as through a cable headend over a cable line, and thus provide richer 

9 information via a video display. Nonetheless, these dedicated devices are often 

10 expensive for individual users, and tend to lack a certain desired versatility. In today's 

1 1 environment of multi-purpose devices, consumers tend to shun relatively large devices 

12 that provide a relatively limited utility, and that tend to be relatively expensive, for such 

13 reasons as lower manufacturing volume than more versatile devices. Further, unlike 

14 these more versatile devices that tend to be covered by local technical agents, 

1 5 maintenance support for a dedicated wagering terminal would be expensive and would be 

16 difficult to offer worldwide, as is desirable. 

17 What is needed is a cost-effective solution for communicating wagering and/or 

18 event information between remote locations and a central location or locations. The 

19 remote locations are preferably enabled for use both in the domestic (home/office) 

20 environment and the retail sector. For reduced cost, the invention preferably uses off the 

21 shelf hardware products at the remote locations, rather than purpose-built, wagering 

22 terminals with fixed data connections. 
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1 SUMMARY OF THE INVENTION 

2 The present invention provides a system and method for interactive wagering 

3 from a location that may be remote from an event being wagered upon. The invention is 

4 preferably implemented on a multi-purpose device, and preferably uses a multi-purpose 

5 communication means, such that a dedicated terminal and/or dedicated line are not 

6 required. Various user-customizable features may be provided. 

7 In one aspect, the invention is designed to function on a store-bought, Internet- 

8 ready PC with a Windows® operating system. All data communications requirements of 

9 are preferably conducted through Internet connections. In embodiments where a dial-up 

10 connection to an Internet service provider (ISP) is used, this may allow mere local call 

1 1 charges for inter-continental data movement. In embodiments where a dedicated line, 

12 such as a digital subscriber line (DSL), cable line, etc., is used, even these charges may 

13 be avoided. Optionally, further functionality associated with a purpose-built wagering 

14 terminal may be provided by including with a remote terminal such devices as a receipt 

15 printer, barcode scanner, credit card reader, etc. 

16 In another aspect, the invention preferably allows wagering based on a deposit 

17 account, whereby funds are registered to an account number in advance of wagering 

18 taking place. The user can stake wagers up to the value held on deposit. Arrangements 

19 may also be made for borrowing funds under any of a variety of circumstances. The 

20 stakes for all accepted wagers may then be debited from the account at the time the bet is 

21 acknowledged as being struck. All winnings are preferably automatically credited to the 
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1 account upon the relevant event location signifying the event is over and that payout may 

2 take place. 

3 In another aspect, the invention can serve the requirements of both the home user 

4 and the retail operator. For home use, there is not a requirement to issue receipts, 

5 although they may be if desired. In addition, so that the home user can be selective as to 

6 which bet details are retained for reference, the user may be given the ability to save and 

7 recall bet files as required. Conversely, the retail version might utilize a receipt printer 

8 and maintain a 3 1-day bet file with individual bet settlement detail, for example. 



9 In yet another aspect, the invention may be implemented through an application 

10 that can initially be loaded on a PC by running a set-up program from a CD or by 

1 1 connecting to a network location, such as a web site, over a network such as the Internet. 

12 Users may achieve upgrades to the application individually, such as by replacing an 

13 executable file, which can be sent via e-mail or download, for example. Alternatively, 

14 the network location may be updated centrally to the benefit of all subsequent users. 
15 

16 BRIEF DESCRIPTION OF THE FIGURES 

17 The invention may be better understood with reference to the following figures. 

18 The figures are intended to be illustrative rather than limiting, emphasis instead being 

19 placed upon broadly illustrating the principles of the invention. 

20 Figure 1 is a block diagram of an embodiment of a system of the present 

21 invention; 

22 Figure 2 illustrates an embodiment of a home page of the present invention; 
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1 Figure 3 illustrates an embodiment of a view ticket page in accordance with the 

2 present invention; 

3 Figures 4A-4F illustrate embodiments of various preference pages in accordance 

4 with the present invention; 

5 Figures 5A-5C illustrate embodiments of today's racing pages in accordance with 

6 the present invention; 

7 Figures 6 A and 6B illustrate embodiments of exacta bet entry pages of the present 

8 invention; 

9 Figure 7 illustrates an embodiment of a trifecta bet entry page in accordance with 

1 0 the present invention; 

1 1 Figure 8 illustrates an embodiment of a superfecta bet entry page in accordance 

1 2 with the present invention; 

13 Figure 9 illustrates an embodiment of a daily double bet entry page in accordance 

14 with the present invention; 

15 Figure 10 illustrates an embodiment of a daily double grid bet entry page in 

1 6 accordance with the present invention; 

17 Figure 1 1 illustrates an embodiment of a pick 3 bet entry page in accordance with 

1 8 the present invention; 

19 Figure 12 illustrates an embodiment of a pick 6 bet entry page in accordance with 

20 the present invention; and 

21 Figures 13A and 1 3B illustrate embodiments of pick 9 bet entry pages in 

22 accordance with the present invention. 
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1 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

2 In one embodiment, illustrated by Figure 1 , a system 100 of the present invention 

3 preferably couples a user location 110, a server location 120 which may include a content 

4 server 122 and a bet server 124, a financial center 130 and an event location 140 over a 

5 network 150. 

6 The user location 110, of which there will typically be a plurality, is preferably 

7 located remotely from the server location 120 and event location 140, such as in a user's 

8 home or office. For example, the user location 110 may be a personal computer (PC). Of 

9 course, the user location 110 could also be at the event location 140, which may or may 

10 not be commonly located the server location 120. Furthermore, multiple server locations 

1 1 120 may be provided, each of which preferably provides content and bet serving 

12 functionality, but which need not include discrete content servers 122 and bet servers 

13 124. Likewise, financial services functionality is preferably, but not necessarily, 

14 provided in the system 100 by any desired means. For example, accounting, lending and 

15 related services may be provided by an independent financial center 130 as illustrated, or 

16 they may be incorporated into one of the other locations, such as the server location 120. 

17 The event location 140 preferably represents a location of an event or events to be 

1 8 wagered upon. The event location may provide bet receiving and settlement 

19 functionality. Alternatively, these functions may be provided by the bet server 124, while 

20 the event location provides upcoming event and/or event result information thereto, 

2 1 and/or directly or indirectly to a user. 



-7- 



02996.0003.NPUS00 



1 The network 150 may be any network, public or private, local or wide-area, or 

2 others. For example, the network 150 may be the global combination of networks known 

3 as the Internet. Thus, the network 150 may include devices communicating by such 

4 means as hard wire transmission, satellite, wireless, etc. To that end, the user location 

5 110 may further include any device capable of communication over the Internet or other 

6 desired network, such as a laptop computer, mobile telephone or other wireless device, 

7 personal digital assistant (PDA), etc. Optionally, means for providing distinct receipts, 

8 such as a bar-coded receipt printer, and/or a means for reading the same, such as a 

9 scanner, may also be provided. 

10 Upon desiring to utilize the present invention, a user preferably initiates a network 

1 1 connection, such as an Internet connection, and establishes connectivity to the content 

12 server 122 and bet server 124 via the server location 120. The content server 122 

13 preferably provides the data required to drive the application, while the bet server 

14 preferably provides a gateway to a wagering system, which may be supported at the event 

15 location 140 or elsewhere. 

16 In one embodiment, so as to be user friendly, a system or device at the user 

17 location 110 is provided with an application that operates under similar navigational 

18 techniques as does Windows Explorer® or a comparable web browser. For example, the 

19 application may be a software program loaded onto a user's PC, PDA or other device of 

20 choice. 

21 Alternatively, the application may be supported at a server side of the system, 

22 such as at the server location 120, with only a user interface being supported at the user 
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1 location 110. The interface at the user location 110 may be communicated over the 

2 Internet or other network in a manner that conforms to a transmission control protocol/ 

3 Internet protocol (TCP/IP), such as by hypertext transfer protocol (HTTP) or other 

4 desired format. For example, as will be appreciated by one skilled in the art, a web page 

5 or series thereof in hypertext mark-up language (HTML), extensible mark-up language 

6 (XML), etc., may be served to the user in response to a request from the user's system. 

7 Regardless, upon initiation of the application, the user is preferably presented 

8 with an introductory view, such as a start-up page of a software program, an Internet 

9 home page, etc. An embodiment of such an intro page or home page 200 is illustrated in 

10 Figure 2. In this embodiment, as in many embodiments illustrated therein, the page is 

1 1 directed toward horse racing. However, this is for illustrative purposes only, as one 

12 skilled in the art will readily appreciate that the invention is applicable to any event upon 

1 3 which wagers may be placed. 

14 As shown in Figure 2, the user may be presented with number of options, 

15 including fastbet 210, for initiating a session; view ticket 220a and 220b, for taking the 

16 user to the current (open) bet file; preferences 230a and 230b, for allowing the user to set 

17 up application details (discussed below), and today's racing 240, for viewing racing 

18 activity. As can be seen, certain options may be presented both in a file tree format 260 

19 and on a tool bar 270. For use in an application supported initially on the user's system, a 

20 connect 250 option may be provided as well for initiating contact with a server of the 

21 present invention. In establishing an Internet connection, users' IP login information may 

22 be required. 
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1 The intro page 200 may be better suited for use by a home user as opposed to a 

2 retail user, but is applicable to both and other environments; Using the intro page 200, 

3 the user preferably has the ability to manage files of bets. For example, a series of bets 

4 can be saved under a file name and new files can be set up and opened. 

5 The toolbar 270 at the top of the page preferably also allows the user options 

6 including new 280, for creating a new file, open 285, for opening an existing file, and 

7 save 290 for saving a currently open file. In one embodiment, these functions are only 

8 available to the home user, while for a retail user, the application automatically creates a 

9 file and saves ticket details on a monthly or other periodic or otherwise selected basis. Of 

10 course, other options may be presented as well, whether visually or by shortcut, for 

1 1 example, such as a betting option for taking the user back to a previously selected race 

12 card, a meeting files option for requesting an update of meeting files for receiving all data 

13 transmitted during a period of off-line use of the system (preferably automated in a retail 

14 application), and a refresh account option, which preferably requests an update to the 

15 user's account balance after wagers are deducted and winnings are credited, among other 

16 transactions. 

17 Upon selection of the view ticket option 220a or 220b, the user is preferably 

18 presented with a view ticket page, an embodiment of which is illustrated as a view ticket 

19 page 300 in Figure 3. The view ticket function preferably allows the user to view a 

20 summary of wagers. The home user might see the particular file open, while the retail 

21 user might see wagers for the last month or other desired time period. Again, however, 
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1 the present invention is not limited to such distinctions between individual or home user, 

2 retail user, and other implementations. 

3 Referring to Figure 3, the following list provides a sampling of potential view 

4 areas that may be revealed in an embodiment of a view ticket page 300: track 310 (3- 

5 character literal ID, e.g. PHI = Philadelphia Park); race 320 (a race number wagered 

6 upon); selections 330 (runner numbers, punctuated by "/" or other selected symbol);-type 

7 340 (3-character literal ID of the bet type; e.g., SFC = Superfecta); cost 350 (total cost of 

8 the transaction); ref. no. 360 (unique bet reference ID); and status 370 (status of 

9 transaction between user and server). Regarding the bet ref ID, this may be generated 

10 either at a pari-mutuel hub or from the user location, such as for already "booked" bets. 

1 1 Of course, the views illustrated and described above, as well as others described below, 

12 are by way of example only. Views may be varied as desired depending on a particular 

13 user, on a betting environment (e.g., for other racing and non-racing environments), for 

14 differing types of wager, etc. 

15 A status applied to a transaction may be any of the following or others: Not 

16 resolved- the transaction has not been requested for settlement, or the event location 140, 

17 which may in this embodiment be a host track for example, has not cleared the result for 

18 settlement. Lost- the transaction has been settled by the Host Track and has a Zero return 

19 to the customer. Win- win certain dollar amount (value preferably in the user's local 

20 currency) or in multiple currencies (further discussed below with regard to preferences). 

21 Paid Win- the user can flag a bet with a positive as "paid." In one embodiment, such an 

22 option is limited to a retail use. Booked bet- a status of "booked" is preferably applied to 
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1 a bet that, in a retail embodiment for example, a "bookmaker" has chosen to stand the 

2 liability, win or lose, rather than to co-mingle the wager back to the host track. 

3 In one embodiment, co-mingling of wagers is used as a mechanism for placing 

4 wagers back to a host track pari-mutuelsy stem. Upon receipt of a bet transaction detail, 

5 the pari-mutuel hub might determine a validity of the transaction by considering such 

6 conditions as 1) whether the event is open for wagering, 2) whether the total stake is 

7 available as a deposited fund, 3) whether the selected bet type (e.g., pool) is available on 

8 the requested event, etc. Upon such validation, a unique bet reference ID is preferably 

9 issued, and may be transmitted back to the user location 110, for example. 

10 Other transaction statuses may be represented in other ways if desired. By way of 

1 1 example and not of limitation, varying background colors for various fields may be used, 

12 e.g., red background (ready to send)- identifies a transaction that has been created off-line 

13 from the Internet. Any bet with a "ready to send" status is preferably sent to the server 

14 location 120 or event location 140 by user action, such as the activation of a "send bets" 

15 option. Blue background (bet placed)- all valid transactions accepted preferably will 

16 have a blue background status. Yellow background (bet rejected)- if a bet is rejected, the 

17 background status will be yellow. This may occur for a late bet, a connectivity failure, a 

18 bet placed against a pool that is no longer available, a bet that overdraws the user's 

19 account, etc. 

20 With continued reference to Figure 3, upon selecting find 375, a user is preferably 

21 presented with any entry mechanism requiring a desired bet number to be entered. The 

22 application preferably scans all bet numbers and locates the match and highlights a 

-12- 

02996.0003.NPUS00 



1 matched bet, such as by a distinct background. If no such bet number is present, the 

2 application may respond by stating that the bet could not be found. If the system has bar- 

3 coded receipts and a scanner the process can be conducted by reading the barcode, while 

4 the manual method preferably continues to be available in event of damaged receipts, for 

5 example. 

6 A pay option 380 is preferably also made available for any bet that has a win 

7 status. Upon finding a bet that has been won, whether by utilising manual scrolling, the 

8 find option 375, barcode scanning, etc., the bet is preferably indicated in some way, such 

9 as by a blue highlight background. If there is a payout value, the pay option 380 will 

10 preferably be available. If the bet has any other status other than win, the pay option 380 

1 1 will preferably be greyed out. If the transaction has a status of paid win, for example, it 

12 will not permit the bet to be paid a second time. 

13 Upon selecting pay 380, the amount to pay is preferably displayed in both US 

14 dollars and the local currency. The local currency may be converted as per the exchange 

15 rate entered through the preference interface discussed below. Upon payment, the status 

16 preferably changes from win to paid win. 

17 Selecting the EOD (End Of Day) option 385 preferably generates a printout, such 

18 as on an optional receipt printer detailing such items as name of bookmaker or operator; 

19 ID number of the specific event site; day, date & time; total number of co-mingled bets 

20 struck that day, bet reference numbers and total stake (including tax if applicable) and 

21 total stakes for co-mingled bets, booked bets and bets of any other type; bet reference 

22 numbers and total payout value for paid winning and unpaid winning bets; total 
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1 winnings; total tax; and balance (with and without tax). All values shown are preferably 

2 in a user's local currency using a preferred exchange rate. 

3 In one embodiment, it is possible for a home user to create bets off-line. Thus, a 

4 remove bet option 390 may be provided for use before connecting to the Internet or 

5 before establishing a connection with the server location 120, so as to not send bets that 

6 are not required and/or desired. If a bet is rejected due a race being closed or the pool 

7 being no longer available the bet may carry a yellow background status, for example. As 

8 this bet is not in the system the user can remove it from the file, thus allowing the user to 

9 view only valid bets. 

10 To simplify a bet settlement function of the present invention, a user may instigate 

11 a bet resolve process. Upon selecting resolve bets 392, any transaction with a "not 

12 resolved" status will preferably have its reference number transmitted to the server 

13 location 120, or wherever such matters are resolved in a particular embodiment, for 

14 evaluation. The location can preferably return any of at least three statuses: 1) Not 

15 resolved- status remains unchanged due to result or result clearance still to be confirmed 

16 from the event location, such as the host track; 2) Lost- host track has determined that the 

17 transaction has a zero return; or 3) Win- settlement determined from the host track, 

18 shown in both US$ and local currency. 

19 After a user has determined that a bet is required in the off-line mode, clicking on 

20 a send bets link 394 will preferably establish an Internet connection, if the user is using 

21 an implementation in which such a connection is not continuous, and transmit all bets 

22 with a status of "ready to send." 
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1 An account balance is preferably also shown in the view ticket mode. The 

2 account may be the summary of all wagers that are co-mingled, for example. Winnings 

3 are preferably automatically accredited to the account from the server or financial center 

4 130 without the user requesting a resolve of bets. The balance may be shown in any 

5 desired currency. 

6 Various user preferences that may be tailored by a user, preferably accessible by 

7 clicking on preferences 230a or 230b, will now be described with respect to Figures 4A- 

8 4F. An embodiment of a view of a preference page is shown in Figure 4A. As can be 

9 seen, such options as cashier mode 410, book limit 420, account 430, settings 440, track 

10 filter 450 and betting 460 may be provided. Figure 4 A illustrates the cashier mode view 

11 400a. 

12 The cashier mode is preferably made available when a printer, such as a bar- 

13 coded receipt printer, is attached. A user can preferably enter such information as the 

14 following: association name (preferably appears on a customer's receipt for reference), 

15 branch ID (such as to provide a further reference to the customer), exchange rate and 

16 local tax rate, among other details. The user can also preferably enter the printer attached 

17 by name. As more printers are accommodated, the list of available printers will increase. 

18 If the desired receipt printer required is not listed, the user can enter such printer 

19 connection details as com port, baud rate, parity, data bits and stop bits. Clicking on 

20 apply activates the details entered, thereby overriding any previous details. 

21 Selecting book limit 420 preferably reveals a page view such as the book limit 

22 view 400b illustrated in Figure 4B. In a retail environment, for example, a bookmaker 
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1 may choose to "book" certain bets rather than co-mingle them back to other pools. The 

2 book limit view 400b preferably provides an interface by which a user can set thresholds 

3 for each individual pool bet type so as to automate the process. If the threshold of all bet 

4 - types is $0 then all bets will co-mingle. If the threshold is $50 for each bet, then only 

5 bets in excess of $50 will be co-mingled to the pools. The user can select any value for 

6 any pool bet type. A sample configuration might be: 

7 • $50 Win Place & Show 

8 • $25 Exacta & Quinella 

9 • $5 Trifecta 

10 • $0 All others 

1 1 Booked bets preferably produce a receipt as per a co-mingled bet, but the 

12 reference number may be generated locally within the application, such as when the 

13 application is a software program or script running independently on the user's system. 

14 Alternatively, the number may be generated from a pari-mutuel hub. 

15 Upon selecting the account option 430, a user is preferably presented with a page 

16 view comparable to the account view 400c of Figure 4C. This view preferably allows the 

17 user to input his or her account number and personal identification number (PIN). Both 

18 of these numbers may be used to validate access to a system of the present invention. 

19 The account view 400c may also show the latest on-line account balance, any fee applied 

20 to access an account balance, etc. The user further preferably has the option to 

21 automatically obtain an account balance upon start-up, which may be achieved in this 

22 embodiment by ticking an update balance box 432. 
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1 In one embodiment, a user has on his or her system an application that acts as an 

2 interface to a system of the present invention. Thus, it may be desirable to provide a 

3 settings page, an embodiment of which is illustrated as a settings view 400d in Figure 

4 4D. This view preferably allows the user to designate a network address that represents a 

5 location of a server 120 of the present invention. As shown, uniform resource locators 

6 (URLs) for the content server 122 and bet server 124 may also be entered. Again, these 

7 servers may be commonly located with or remotely located from each other. In one 

8 embodiment, the application only utilizes one content server 122. In another 

9 embodiment, additional content servers 122 may be added and thus additional addresses 

10 inserted using the settings view 400d. Multiple servers could be accessed to expand the 

1 1 functionality beyond a single pari-mutuel wagering application, for example. 

12 Referring next to Figure 4E, an embodiment of a track filter view 400e is 

13 illustrated. Because the present invention may be used to access totalisators associated 

14 with wagering data for a wide variety of events, it may be desirable to limit displayed 

15 data to a particular user's interests. For example, a user may limit the data to only 

16 official horse and dog based wagering, or to Jai Alai. In the embodiment illustrated, the 

17 filtering is achieved by the tick boxes 452 associated with thoroughbred, harness and 

18 greyhound racing, as well as jai alai. Of course, countless other options may be 

19 available. Ticking the required boxes 452 preferably restricts the display to cover only 

20 that specific wagering type or types, as multiple or all wagering types can be selected. 

21 Furthermore, individual track requirements can be managed by using add and remove 
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1 tiles 454 and 456, allowing the user to tailor the display to specific tracks regardless of 

2 wagering type. 

3 Selecting betting 460 preferably reveals a page view such as the betting view 400f 

4 illustrated in Figure 4F. The betting view preferably allows the user to load default stake 

5 values for individual bet types. This action assumes the stake when a bet detail is 

6 entered. Of course, the defaults can be over-written, if desired, at the time of striking the 

7 bet, such as by clicking on stake and selecting a different value or by entering the 

8 required stake into the stake box. Additional options may be provided regarding 

9 presentation of the latest tracks wagering. Default pool display buttons 462 are illustrated 

10 for the purpose of selecting between them. For example, it can show the probable 

1 1 payouts to a $2 stake or it can show the latest pool standings. Other options may be made 

12 available as well. 

13 Regarding the display preferences portion 464, betting odds can be shown with or 

14 without the inclusion of the '71 " if desired. For example, five to one odds could be 

15 shown either as "5" or "5/1." Likewise, odds formats may be selected between such 

16 options as 'same as TV and Internet,' 'Philadelphia Park/ 'New York Racing 

17 Association (NYRA)' and 'United Kingdom & Republic of Ireland,' among others, using 

1 8 an odds type pull down menu 466. 

19 Referring next to Figures 5A-5C, various embodiments of a system and method of 

20 the present invention for interactive wagering will be described. Figure 5 A illustrates a 

21 today's racing page 500a, preferably displayed when a user selects a today's racing link 

22 240a or 240b. Upon connection to the content server 122, the application preferably 
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1 determines what data is required. In one embodiment, this is achieved by the application 

2 knowing the sequential number of the last data packet it received. A request may then be 

3 submitted to obtain all subsequent data beyond that last received packet. This approach 

4 to data set-up can enable the user to come off-line at any time, and upon re-establishing 

5 communications quickly get back up to date. 

6 Data exchanged in accordance with the present invention may be in any suitable 

7 format. As discussed above, data packets or records may be used. The data packets 

8 preferably conform to a predefined specification, which may provide a strict record 

9 definition and/or allow variable length, structure, etc. In one embodiment, the first three 

10 fields of most record types contain a common structure. The first is a record code that 

1 1 describes the record level and forms a part of a packet identifier. The second is a record 

12 sub code that combines with the record code to form the unique packet identifier. The 

13 third is a meeting code, which is preferably a unique code that may be used to identify a 

14 race meeting, for example. Preferably, once the code is defined in a meeting record, it 

15 remains constant and is used throughout subsequent packets as a means of referral. 

16 Meeting codes may also be further predefined. In one embodiment, meeting 

17 codes consist of 8 alphanumeric characters and are unique for each meeting. Preferably, 

18 for compatibility with existing systems, the code will contain sufficient redundancy so as 

19 to allow a variety of processing methods. The code may be made up as shown in Table 1, 

20 for example: 
21 

22 
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1 Char 


Key 1 


Key 2 


K ey 3 


Content 


i 






I'M? - 1 


Year code (0=2000, 1=2001, etc.) 


2 


Main key 






Any hexadecimal digit 0-9 or A-F. 


3 


(SDS 


A ■ : ' "*& - • 


. y >V T^- '*" '■' *'*"*-' ' ". ' ' 

S \ • >i<i ." - ' /■ 


Each combination will be unique 


4 


style) 


tfi, >. t * . c 




within a calendar year. (Allows 
approx 45,000 "meetings per year). 










5 








Month code (A=Jan, B=Feb, .. 
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Table 1 



Potential methods of use for one embodiment are as follows: 

o Main key. This key is preferably compatible with software that supports a suitable 
data feed, such as the SIS Sports Data Service feed. The key preferably consists of 4 
hexadecimal digits, the first of which is (by convention) a code for the current year. 
Clients using this key may ignore the other 4 characters, but might need to build some 
form of meeting table in their database. This will allow, for example, all of the 
meetings on a particular day to be located and enumerated. 

o Alternative key. In one embodiment, this key is larger but provides a built-in date 
structure. It consists of 5 characters, 3 of which represent the meeting's performance 
date, and two of which provide a sequencer (described below) into the meetings for 
that date. Users of this key may ignore the 3 hexadecimal characters used by the 
main key. 
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1 • Daily key. This key is preferably compatible with software that supports a raw data 

2 feed, such as the original SIS Raw Data feed. To use this method, clients may filter 

3 the data for the current day's meetings only. The year, month and day codes can be 

4 used to achieve this. The key preferably consists of a two-character sequencer only , 

5 and this is based upon the original SIS Raw feeds use of a single letter A to X. 

6 However, some events consist of substantially more than 24 meetings per day. To 

7 support more meetings than this, the feed preferably utilizes a second 'batch number' 

8 character. The meetings of the day will therefore be numbered 1 A, IB, ... IX, 2 A, 

9 . . ,2X, 3 A, . . etc., or by some other suitable convention. 

10 If a particular track operates two meetings on the same day (e.g. an afternoon and 

1 1 an evening meeting), for example, then these will preferably be allocated separate keys 

12 under all three methods. Again, however, as one skilled in the art will readily appreciate, 

13 the above data specification description is by way of example only. Many alternatives 

14 are available depending on a particular implementation of the invention. 

15 Regardless of a chosen data format, the content server 122 is preferably 

16 responsible for delivering the raw data from which the user's application builds the user 

17 interface. As discussed above, this data may be used by an application running on the 

18 user's system, or may include all or most necessary data, such as in the form of a page or 

19 pages in an appropriate mark-up language for use by a browser application, for example. 

20 Regardless, incorporated within the data feed are preferably static details, which may 

21 define the meeting, events and pools, and live updates, among other things, detailing 

22 snapshots of the win pool. These features may be depicted as odds and pool sizes for 
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1 place, show, exacta, quinella, etc. Having determined event coverage required via the 

2 track filter, discussed above, the application will preferably apply these filters to the data 

3 feed received. 

4 On the today's racing page 500a, a list of tracks or other locations holding races 

5 or other events that day is preferably illustrated in a track portion 505. After applying the 

6 track filter to achieve a list of tracks of interest and that have events, each wagering type 

7 is preferably depicted with a symbol to indicate such details as racehorse, harness rig, 

8 greyhound, etc. When a track has completed all its events, the symbol is preferably 

9 replaced with an "x" or other indicator to show that no further events are available. All 

10 tracks in the track portion 505 preferably have a "+" symbol that can be clicked on to 

1 1 expand the data shown. 

12 Utilizing this Windows Explorer® or other browser-type navigation, each track 

13 can preferably be expanded to show the events taking place at a certain location. Before 

14 any live updates are received, the expansion might show Race 1, Race 2. . .Race 10, for 

15 example, to show the total number of events scheduled at the selected venue. As racing 

16 progresses the status of the next event might be updated with a minutes to post (MTP) 

17 record indicating how long until the next race is scheduled. The MTP record could 

18 appear, for example, as: Race 3 (23MTP). Nearer to the race time, the MTP status might 

19 change to "P/T" for Post Time. The P/T might then subsequently change to "OFF," 

20 indicating pool closure. An additional symbol, such as a red "x" appearing next to the 

21 event, could also show the off status. 
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1 With continued reference to Figure 5 A, it may be seen that in this embodiment, 

2 the today's racing page 500a includes a pools available portion 510, indicating which 

3 pari-mutuel pools are available for a selected individual event. This information may be 

4 obtained by the application from the data feeds provided by the server location 120, for 

5 example. Such pools, some of which are illustrated in Figure 5, might include win (W)- 

6 nominating the selection to finish in 1 st position; place (P)- nominating the selection to 

7 finish in 1 st or 2 nd position; show (S)- nominating the selection to finish in 1 st or 2 nd or 3 rd 

8 position; exacta (EXA)- nominating 1 st & 2 nd to finish in correct order; quinella (QIN)- 

9 nominating 1 st & 2 nd to finish in either order; trifecta (TRI)- nominating 1 st , 2 nd & 3 rd to 

10 finish in correct order; superfecta (SFC)- nominating 1 st , 2 nd ' 3 rd & 4 th to finish in correct 

1 1 order; daily double (DDB)- nominating the 1 st places in 2 designated races; pick 3 (PK3)- 

12 nominating the 1 st places in 3 designated races; pick 6 (PK6)- nominating the 1 st places in 

13 6 designated races; pick 9 (PK9)- nominating the 1 st places in 9 designated races; among 

14 others. 

15 As illustrated, for each type of bet, odds are shown in a track odds indicator 

16 column 515 for each entrant. In addition, pool sizes 520 for various bets are shown for a 

17 current stake, indicated by a stake portion 525. For example, in the embodiment of 

18 today's racing page 500, a win column 530, a place column 535 and a show column 540 

19 are shown. Function tiles 545 and a deposit balance indicator 550 are also provided, as 

20 discussed previously. 

2 1 Assuming that WPS are valid pools, the user might click in the appropriate 

22 column (WPS) for the requested selection. In Figure 5B, an embodiment of a today's 
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1 racing page 500b is shown. Clicking within the win column 530 of Figure 5 A preferably 

2 produces bet details such as those shown in the details portion 555. The stake unit 

3 applied will be as per the default win stake applied in a user's preferences/betting 

4 information. If the stake requires changing, pressing the-stake tile 560 preferably reveals 

5 the available stake calibration 565. For example, values of $2, $3, $4, $5, $6, $7, $8, $9, 

6 $10, $15, $20, $25, $30, $40 and $50 might be available. If the required stake is not 

7 shown, it can preferably be simply entered in the stake box 570. 

8 Referring to today's racing page 500c of Figure 5C, an example is shown in 

9 which WPS bets are placed for a customer, in a retail situation, by a user (e.g. a 

10 bookmaker) as follows: $2 on number 6 to win, $2 on number 3 to place and $2 on 

1 1 number 5 to show. Upon confirming these details, the user commits them for co- 

12 mingling (assuming "0" threshold for booked bets) by pressing the send bets tile 575 of 

13 the bet options portion 580. As above, details are preferably provided in a bet details 

14 portion 590, while a total ticket value may be shown in a total portion 595. 

15 At this point, the system or systems preferably require the user to confirm the 

16 total stake, which is shown in both US dollars and the value determined by applying the 

17 exchange rate and tax rate entered through user preferences. Upon confirmation from the 

18 customer, the user presses yes in a confirmation box 585. The system ascertains that 

19 there are sufficient funds available for the wager(s) and upon verification, the 

20 transactions details are preferably transmitted to the server location 120, or other relevant 

21 location. If insufficient funds are available, this would preferably be reported to the user 

22 and the wager or wagers not permitted. 
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1 Preferably, as illustrated in the bet options portion 580, the user has options 

2 including the following: Next bet- allows the user to move on to another event or wager 

3 type having secured the bet detail without transmitting them to the server location 120. 

4 Start over- allows the user to scrap all bet details entered that have not-been transmitted 

5 and start over again. Clear- fulfills the same function as start over but restricts the clear 

6 to highlighted bets. Clear bet- allows the user to remove an individual bet from those that 

7 are ready to send. View ticket- moves the user to the view ticket mode. Send bet- 

8 transmits all bets to the hub when in an online mode or flags them as ready to send when 

9 in offline mode. Of course, one skilled in the art will appreciate that these options are not 

10 limiting, as many others are possible. 

1 1 Upon receipt of an acknowledgement from the server location 120 or other 

12 relevant location, a confirmation is preferably shown and a receipt printed (if printing 

13 means are attached). The application then might query if the user wants to switch to view 

14 ticket mode or to continue from the event- wagering screen, for example. The user's 

15 deposit balance is preferably also adjusted to reflect the total cost of the wagers 

16 transmitted. 

17 With reference to Figures 6A and 6B, embodiments of views that may be 

18 presented for varying bet types will be described. Preferably, for simplicity, the same or 

19 similar pattern of validation, confirmation and acknowledgement exists regardless of a 

20 wager type selected. While different wager types might have different selection entry 

21 routines, staking and/or other features may be constant. Of course, this need not be the 
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1 case if such is not desired, as a wide degree of customization is contemplated with regard 

2 to the present invention. 

3 Referring to Figures 6 A and 6B, embodiments of exacta bet entry pages 600a and 

4 600b are illustrated. The exacta requires a selection to be made in the 'first 5 column 610 

5 and another selection in the 'with 5 column 620, as shown in view 600a. One selection in 

6 each meets the minimum requirements for an exacta. In this embodiment, the application 

7 further allows these two selections to be "boxed 55 by pressing a box button 615, which 

8 effectively creates a second exacta bet. For example, a 4/7 exacta requires racer 4 to 

9 finish first and racer 7 to finish second, while a 4/7 boxed places two bets, one on the 

10 sequence just described, and a second on racer 7 to finish first and racer 4 to finish 

1 1 second. As above, details may be shown in a bet details portion 625. 

12 The application also preferably permits full-cover permutations by use of the 

13 boxed facility. For example, a 4/7/8 full-cover boxed exacta covers any two of the three 

14 racers finishing first and second in any order (e.g., 4/7, 7/4, 4/8, 8/4, 7/8 and 8/7). The 

15 application also preferably permits non-full-cover permutations. For example, in a '4, 

16 7/8 5 bet, a winning bet has racer 8 finishing second and either racer 4 or racer 7 finishing 

17 first. The boxed and multiple selection concept also preferably applies to quinella, 

18 trifecta, superfecta, etc. 

19 Referring next to view 600b, exacta and quinella wagering, for example, may be 

20 displayed in an alternative view. In this embodiment, a matrix detailing all possible 

21 permutations is displayed. Each element preferably shows either the pool total or the 

22 probable payout assigned to that outcome. The pools may be updated as desired from the 
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1 data feed received, and therefore the probable payout tends to become more accurate as 

2 the time for pool closure nears. 

3 As illustrated in this embodiment, the left-hand column shows the 1 st position 

4 630, while the top row shows the 2- d position 640. Reading do wn and across gives either 

5 the probable payout or the pool total for the element. The quinella may use a similar 

6 architecture if desired. However, rather than selecting 1 st and 2 nd , the user can preferably 

7 click on the required combination, which writes the bet detail in the previously described 

8 fashion. On the exacta and quinella interface, the user can further preferably toggle 

9 between a "grid" view and a "standard" view as desired. 

10 For illustrative purposes only, Figures 7-12, 13A and 13B illustrate embodiments 

1 1 of views that may be provided for additional bet types, including trifecta 700 (Figure 7), 

12 superfecta 800 (Figure 8), daily double 900 (Figure 9), daily double grid 1000 (Figure 

13 10), pick 3 1100 (Figure 11), pick 6 1200 (Figure 12) and two embodiments 1300a and 

14 1300b of a pick 9 view (Figures 13A and 13B). 
15 

16 Conclusion 

17 While various embodiments of the present invention have been described above, 

18 it should be understood that they have been presented by way of example only, and not 

19 limitation. For example, the present invention is not limited to the physical arrangements 

20 described or use with any particular network or data format. Likewise, the invention, 

21 while described in part with respect to wagering on racing events, is applicable to any 
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wagering environment. As such, the breadth and scope of the present invention should 
not be limited to any of the above-described exemplary embodiments. 
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